The 1553 bus has been defined by the Department of Defense as an asynchronous, serial, time division multiplex bus. In a typical 1553 system, there will be one central computer (such as a fire control computer on an airplane) and a number of other units on the bus which are referred to as remote terminals (RT). The detailed bus requirements are defined in a number of available publications, including the MIL-STD 1553 Multiplex Applications Handbook from SCI Systems, Inc., of Huntsville, Ala. The standard also allows for three word formats--command words, data words, and status words, having the obvious functions. The bus standard also provides for three catagories of message formats--message transfers between any two remote terminals (RT to RT), transfers from the bus controller to a particular terminal; mode commands for terminal management; and broadcasts to all remote terminals.
Existing implementations of the functions of the bus controller within the system have been done using hybrid circuits comprising several chips on a printed circuit board. An example of this approach is that of the Data Device Corporation's chip set called BUS-66300, BUS-66305, BUS-66106 and BUS-66111. An important drawback of these and other implementations of the bus controller is that the system CPU (the Central Processing Unit in the main system computer) is required to interact with the bus controller device for every 1553 command that is executed or after a small number of 1553 commands. Since the 1553 bus is a real time bus, in which the bus controller and the remote terminals must respond within strict time constraints, any interaction with the CPU both degrades the response of the system and also serves to load down the central computer. A further load on the central computer is the necessity for the CPU to reconfigure the message sequence that is being sent over the bus in order to respond to events that have sent an interrupt signal to the CPU. Another drawback of some previous systems is that there have been fixed requirements on the memory areas used and the size of those areas. Both of the above problems require more intervention by the CPU.
There has been a long felt need for a subsystem that could take from the CPU the burden of managing the bus and carrying out a programmed sequence of messages and commands over the bus.